家裡的 Agent 燒錯 $40，是學費；企業的 Agent 做錯一筆，是事故——可能是監理報告上的事故。

白天在金融業寫系統、晚上在家養 Agent 的這半年，我腦中一直有個平行對照：家裡這套治理（閘道、路由、評分、紅線），放到銀行等級的環境會發生什麼事？哪些直接能用？哪些差了十萬八千里？

先把免責講在最前面，因為這篇最容易被誤讀：

**這是一場思想實驗，不是一份建議書。**談的是任何受監理的金融機構都會遇到的通用課題，不涉及任何特定公司的實務、也不代表我有資格設計機構級的治理框架——我沒有。這只是一個在家治理過小系統的工程師，對照自己白天看到的東西，做的一次沙盤推演。

這麼寫的用意，其實是倒過來的：我想弄清楚家裡那套東西的天花板在哪。搞清楚它「不能做什麼」，比宣稱它「能做什麼」有用得多。

差距盤點：四個「家裡沒有、銀行必須有」

拿 Day 28 的四支柱當基準，跟金融級要求對照，缺口集中在四個地方：

審計軌跡的差距最本質。我家的 log 回答「哪裡壞了」，金融級的 audit trail 要回答「三個月前的那個自動決策，是基於什麼輸入、哪個模型版本、哪條規則做出的」——而且要抵擋「事後有人想改紀錄」。對 LLM 系統這特別難：同樣的輸入不保證同樣的輸出，重建決策過程意味著要留存 prompt、模型版本、參數、甚至當時讀到的資料快照。我家的晨報寫錯了頂多重跑，銀行的自動決策要能被稽核員逐筆還原。

權限分級是我在家最「奢侈」的違規：我一個人就是全部角色。Day 24 的品質閘道約束的是「粗心的我」，但約束不了「惡意的我」——家裡不需要，機構必須假設任何單點都可能出錯或作惡。對應到 Agent 系統：改 prompt 算不算變更？要不要過變更管理？我的答案是要——prompt 就是行為規格，行為規格的變更就是版本變更。這在我家是一份 git commit，在機構要是一張變更單。

模型風險管理在金融業有專門的監理框架（模型驗證、定期重檢、模型清冊）。傳統上管的是信用評分卡這類統計模型；LLM 讓這件事複雜一個量級——模型是外部供應商的、會被升級、行為無法完全複現。我家 Day 23 的「模型會退役，當常態設計」在機構語境會長成一整套供應商與版本治理。

資料駐留在我家是一個勾選框（「這份資料要不要給雲端 LLM 讀」），在機構是法遵題：個資、客戶交易資料能不能進第三方模型 API？要不要地端部署？這也是為什麼企業界對地端／私有化 LLM 的需求這麼硬——很多場景不是成本考量，是資料根本出不了門。

值得補一句的是：這四個缺口在我家的系統裡其實都已經有胚胎，差的是縱深而不是有無。審計軌跡——排程的執行紀錄已經留存每次的輸入、模型、投遞結果（Day 25 靠它抓過假失敗），缺的是防竄改與資料快照；職責分離——程式變更走「分支 → PR → 測試閘道 → 合併才部署」的流程（Day 27 提過），這條 pipeline 就是變更管理的雛形，只是審核者和開發者是同一人；模型風險——三層路由白名單（Day 23）就是一份最小模型清冊；資料駐留——「哪些檔案 LLM 可讀、哪些只放指標不放值」的分層（Day 26）就是邊界意識的起點。從家用到機構級，不是換一套東西，是把每一條的「一個人版本」長成「組織版本」。

風向：這題正在變成必答題

這一段我不打算扮演法規專家——各國的 AI 監理框架，新聞都讀得到，我沒有比記者懂。我能提供的只是一個在金融 IT 裡工作的人的日常體感：AI 治理這題，在這個行業的氣氛裡，正從「前瞻議題」變成「遲早要交卷的題目」。內部討論新系統時，「模型怎麼管」「決策能不能重建」「資料出不出得了門」這類問題出現的頻率，一年前後完全不是同一個量級。

有趣的是回頭看我家那份品質閘道（AGENTS.md）：哪些模型能用、哪些動作要留痕、哪些操作不給工具——把它翻譯成合規語言，結構上就是一份微型的風險清冊：每一條規則對應一個已識別的風險、一個控制措施、一個負責人（雖然負責人全是我）。我寫它的時候完全不是為了合規，只是被 $40 的帳單教育過。

這給了我一個有點意外的體會：「讓一個會自己行動的系統不闖禍」，在家和在機構本來就是同一道題——差別只在闖禍的代價，和監督你的人是誰。家裡擋的是粗心，機構擋的將是罰則；規則的內容會變，但「用封閉規則圈住機率系統」的形狀不會變。

反向盤點：真正帶得走的是什麼

推演到這裡要誠實一件事：機構環境比家裡複雜得多、也受限得多——資料不能亂丟、工具不能亂裝、每個動作前面都有審批。而且連 token 都是公司資源：花下去的每一分都要對得出產出，不像在家可以燒 $40 買個教訓——試錯的空間本身，在機構裡就是奢侈品。家裡那些「做法」，多數不能直接搬。我後來想明白，真正能跨過那道門帶進機構的，不是規則清單，是長在人身上的東西：

一、跟 AI 協作的方式與習慣。半年天天跟 AI 一起改系統，養出來的不是某項技術，是一整套習慣：怎麼把任務講清楚（格式契約）、怎麼審它的產出（看它假設了什麼，而不是語法對不對）、什麼時候該懷疑它（它從不報錯，只會演）、驗證要反向做（塞個假故障看它會不會叫）。這些習慣不需要申請權限、不需要採購流程，隔天上班就在身上。

**二、「這能不能用 AI 解」的反射。**在家把生活場景一個個餵給 AI 之後，看工作場景的眼睛會變：哪些是模板任務、哪些需要人在場、哪些交給確定性腳本就好——這套判斷力（Day 23 的路由直覺）在機構語境一樣成立，而且機構的場景更多、更雜，這個反射反而更值錢。

至於那些具體原則——預設值審查（Day 22）、封閉規則優於開放原則（Day 24）、成本當一級指標、誤報是 P1（Day 25）——它們仍然成立，但在機構裡是「觀念可參考」，落地要過的關卡比家裡多一個量級。帶得走的是能力和直覺；做法，到了那邊要重新長一次。

這也是「家是沙盒」真正的價值所在：試錯在家裡完成，錯誤成本自己吸收，帶去公司的是已經試完錯的習慣——公司的 token 花在產出上，而你的學費，在家裡已經繳過了。

還有一層常被忽略：在家餵給 AI 的都是自己的資料——記憶、行程、持倉，洩漏了心疼的也只有自己；在公司，連「這段程式碼能不能貼給 AI」都先是一道資安題、一道機密分級題。家裡幾乎不存在的那類風險，正是機構裡最貴的那類——這也解釋了為什麼練功要在家練：不只因為便宜，是你可以把注意力全放在「怎麼用好」，而不是「能不能用」。

開放問題：Agent 自主性 vs 內控

最後留一個我沒有答案的問題。

Agent 的賣點是自主性——它自己判斷、自己執行，人不在迴路裡。內控的邏輯恰恰相反：重要動作要有人審、要職責分離、要事前授權。這兩個邏輯在根子上是打架的。

有趣的是，我家裡這套系統其實已經用腳投票了：多數排程是零 LLM 的固定腳本；少數會呼叫模型的，也只用 Gemini 免費額度或 Claude Haiku、且任務邊界很窄，Claude 旗艦完全不出現在無人看管的排程裡（Day 15 講過原因）。我不是為了合規才這樣設計，是因為確定性的事情交給確定性的程式，本來就比較好用。而這個出於實用而做的選擇，恰好就是內控會喜歡的形狀。

這讓我懷疑一件事：Agent 自主性與內控的衝突，也許沒有想像中那麼難解——難的不是取捨，是分辨哪些事情根本不需要自主性。

家裡我的解法是分層：低風險動作全自主（發報告）、中風險自動做但留痕（重啟容器）、高風險不給工具（刪檔、改排程設定）。這個「按破壞半徑分級授權」的思路我相信可以外推，但金融場景的難點在於：很多動作的風險是事後才知道的——一則發給客戶的自動訊息，措辭偏差可能就是申訴案件。LLM 的輸出空間無法窮舉，授權分級的顆粒度要切到多細才夠？「人在迴路」要留在哪些環節才不至於把 Agent 退化回工作流引擎？

我猜這會是接下來幾年整個行業一起摸索的題目。個人系統是很好的沙盒——在家裡，你可以讓 Agent 犯錯犯得起，然後把每一次犯錯都變成治理規則。這個「先在低風險環境長出規則」的路徑，本身可能就是答案的一部分。

小結＋明日預告

推演的結論：個人治理和機構治理的原則同源（縮小風險邊界、封閉規則、可觀測），差的是縱深（審計、職責分離、模型風險框架、資料駐留）——而行業的風向正在把這個縱深從「自我要求」推向「必答題」。家用系統是治理思維的健身房——舉的重量不同，動作是一樣的。

明天是最後一篇。30 天寫完我的 AI 管家：這半年的成績單——運行數據、最有價值的四個決定、付了學費的四個錯誤，以及接下來要去哪。

🔑 這篇的關鍵字
（本篇是思想實驗，非建議書）機構級 AI 治理的四個縱深：稽核軌跡 · 職責分離 · 模型風險管理 · 資料駐留
微型風險清冊——家用系統的品質閘道翻譯成合規語言就是它：每條規則＝一個風險＋一個控制＋一個負責人
Agent 自主性 vs 內控的張力 · 按破壞半徑分級授權 · 人在迴路（human-in-the-loop）該留在哪些環節
一個實務觀察：分辨「哪些事根本不需要自主性」，比在自主性與內控之間取捨更有用

我是一名金融業資訊工程師，這是我半年來在家自架 AI Agent 系統的實錄。